🍿 ! "and so it begins..."

I wonder though - this seems like a lot of repetition required in 2x the places (alters modular and old-style implementations), and 2x the work since there will be removal required in the modular API when deprecation complete

Related thought: the modular implementation will eventually host the actual implementation, inverting the current situation where old-style has the implementation and modular delegates, that is a necessary change that is unavoidable when removing the old-style implementation

So with this style it is:
1- add deprecation machinery to modular and old-style (2 spots)
2- move implementation from old-style to modular (unavoidable)
3- remove old-style and deprecation machinery from modular (2 spot)

I wonder if re-ordering it would be more efficient, and lead to cleaner deprecation addition:

1- move implementation from old-style to modular (unavoidable anyway)
2- add deprecation to old-style (only 1 spot, doesn't pollute modular)
3- remove old-style (only 1 spot)

🤔

the boilerplate here bothered me (though I thought the idea was fine after discussion, and when I saw it again on #8132 I tried #8135 which seemed to work

If #8135 seems okay, then merging that one first, then using it in this one would make this diff tiny I think